A long running issue, which I covered in my previous posts: https://geekmungus.co.uk/?p=3532 and https://geekmungus.co.uk/?p=3593, this should be taken as the current status of the problem and the resolution.
Issue
Following the patch: KB5021131 CVE-2022-37966, which was released November 8th 2022 we’ve continued to have some issues with Kerberos authentication to servers (devices) that use (and can only use) RC4 ciphers. We have some old NetApps we are about to migrate off of which have been experiencing issues.
Removing the patch from the domain controller resolves the issue, however this was only a shortlived resolution, we then get the same issue again.
Following the KB5021131 CVE-2022-37966 update the issue reappeared, but we needed a workaround (until the storage could be retired) that didn’t involve days of effort removing patches manually, the below did not work when tried on the previous patch (KB5021131) but did work this time on the later more recent patch. To resolve the issue we finally did the following:
For all intents and purposes, once the patch is applied it assumes any user, computer account etc. where the attribute: msDS-SupportedEncryptionTypes is blank assumes that now only supported “Session Key” (inside key) types are AES-128 and AES-256.
Now that’s great from a security point of view, but in our case we are running some very old NetApps that don’t support AES-128 and AES-256 that just needed to work.
But these don’t support AES just RC4. So we still needed to ensure it keeps working (for now).
Resolution
Using ADUC set the “msDS-SupportedEncryptionTypes” attribute on the computer objects of the NetApps that are experiencing the issue.
You would set the attribute to the following (for RC4).
msDS-SupportedEncryptionTypes = 0x4 (Hex)DES_CBC_CRC = 0x01 DES_CBC_MD5= 0x02 RC4_HMAC_MD5 = 0x4 AES128_CTS_HMAC_SHA1_96 = 0x08 AES256_CTS_HMAC_SHA1_96 = 0x10
For example, 0x1c indicates support for RC4_HMAC-MD5, AES128_CTS_HMAC_SHA1_96, and AES256_CTS_HMAC_SHA1_96, this is calculated as the sum of the values.
This sets this encryption type as the only supported type by these computer objects. Post the patching being applied.
What this means then is that any server/service which cannot use AES-128 or AES-256 in its session keys (inside keys) would need to have this attribute set.
Example Output
In this example output below, you can see that NetApp10 isn’t working, its got the “Session Key Type” of AES-256-CTS-HMAC-SHA1-96 because it has yet to have the above attribute set on the account. But the NetApp1 is working, its showing the “Session Key Type” of RSADSI RC4-HMAC(NT) because we’ve forced it to this version: msDS-SupportedEncryptionTypes = 0x4 (Hex) via the attribute on the computer accounts.
C:\Users\username>klist
Current LogonId is 0:0xc47e6
Cached Tickets: (4)
#0> Client: username @ DOMAIN.COM
Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 1/3/2023 14:57:14 (local)
End Time: 1/4/2023 0:57:14 (local)
Renew Time: 1/10/2023 14:57:14 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC-01.domain.com
#1> Client: username @ DOMAIN.COM
Server: cifs/netapp10.domain.com @ DOMAIN.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 1/3/2023 15:04:55 (local)
End Time: 1/4/2023 0:57:14 (local)
Renew Time: 1/10/2023 14:57:14 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC-01.domain.com
#2> Client: username @ DOMAIN.COM
Server: cifs/powerscale1 @ DOMAIN.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 1/3/2023 15:03:18 (local)
End Time: 1/4/2023 0:57:14 (local)
Renew Time: 1/10/2023 14:57:14 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC-01.domain.com
#3> Client: username @ DOMAIN.COM
Server: cifs/netapp1.domain.com @ DOMAIN.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 1/3/2023 14:57:14 (local)
End Time: 1/4/2023 0:57:14 (local)
Renew Time: 1/10/2023 14:57:14 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: DC-01.domain.comAdditional Information
- https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-do-i-know-if-my-ad-environment-is-impacted-by-the-november/ba-p/3679869
- https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/what-happened-to-kerberos-authentication-after-installing-the/ba-p/3696351 (There is a useful script on this page.)
- https://docs.centrify.com/Content/config-unix/adclient_prevalidate_allow_users-EncryptionTypes.htm
- https://support.microsoft.com/en-gb/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d
- https://syfuhs.net/kerberos-event-id-27
- https://www.technipages.com/windows-how-to-switch-domain-controller
If we don’t want to address this account by account, can we simply add a GPO with a group policy preference to add 0x1c to the following registry key:
\\KEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC\DefaultDomainSupportedEncTypes
to allow RC4 session keys?
Yes, this was the first thought, the above would registry key change would need to be added to all of the DCs to ensure that was the default offered.
In our case when this was added to our domain controllers, it had no effect with: KB5021131 even after reboots of the domain controllers. In our case adding the attribute to the computer object was all that worked.
However the above registry key change should work for others.